LLM 的注意力是 U 型曲線

LLM 對長 context 的注意力是 U 型曲線 — 開頭看得到、結尾看得到、中間幾乎跳過。這不是猜測，Stanford 的 "Lost in the Middle" 論文實測過：把正確答案藏在一長串文件的不同位置，放中間準確率直接掉 30-50%。

這個問題到現在還沒被根治。各家模型在 needle-in-a-haystack 測試拿到 99%+ 的召回率，但那是「找一根針」的簡單任務。換成複雜推理，中間位置的資訊還是容易被跳過 — 因為 transformer 架構裡 RoPE 的 long-term decay 讓中間 token 天生拿到較低的 attention weight。

你塞給 AI 一萬行 context，它可能只認真看了頭尾各一千行。中間那八千行不是被「理解」了，是被跳過了。

Context 品質 > Context 數量

Anthropic 在 Claude Code Best Practices 裡直接講了："Bloated CLAUDE.md files cause Claude to ignore your actual instructions." 指令檔太肥，AI 會直接忽略你的規則。直覺告訴你資訊越多越好，但實測結果相反 — 塞越多，AI 表現越差。

社群裡有大量實測印證這件事。DEV.to 上幾篇 CLAUDE.md best practices 文章的共識是：超過 200 行的單一指令檔，AI 的遵從率會漸進式下降。不是突然不聽，是「有時候」不聽，而且你無法預測是哪一條被忽略。

這比完全不聽還糟。因為你以為它知道規則，就不會特別去 review 那些「它應該會處理好」的部分。

拆檔：同樣的資訊量，不同的載入策略

解法不是少寫規則，是改變載入方式。

Claude Code 的 rules 機制支援將規則拆成多個獨立檔案，放在 .claude/rules/ 底下，按需載入而不是全部塞進同一份。

以實際運作中的設定為例，拆法的思路是這樣的：

全域規則（不管做什麼都需要知道的）放 CLAUDE.md，控制在 50 行以內 — 專案是什麼、動手前要確認什麼、什麼時候該停下來問。

領域規則（只在特定情境需要的）各自獨立成檔 — 安全規則一份、測試規則一份、Git 規範一份、前端測試一份、後端測試一份。每份 30-80 行。

這樣 AI 每次看到的是「通用 + 當前相關」的規則，而不是「所有領域的所有規則」。總行數沒變，但每次載入的量少了，訊號密度高了，遵從率明顯提升。

這不是 Claude Code 獨有的問題

如果你用過 Kubernetes，它的 ConfigMap 也是同一個道理 — 你不會把所有服務的設定塞在同一個 ConfigMap 裡。Nginx 的設定拆成 sites-available / sites-enabled。Linux 的 sudoers 用 sudoers.d/ 拆分。

所有長壽的設定系統最後都走向同一個結構：一個精簡的主檔 + 按需載入的模組。因為維護者發現，單一大檔在規模成長後必然失控。

AI 的 context 管理也不例外。它不是一個新問題，是一個用新形式出現的老問題。